This event occurs when the libvirt global error handling function is called and virErrorLevel indicates a warning has been raised (i.e. VIR_ERR_WARNING) most likely due to an API call. The arguments for this event are: - errorMessage: Provides the reason for the failure. - errorCode: The virErrorNumber from the virterror module of libvirt API. - errorDomain: The virErrorDomain from the virterror module of libvirt API. For further details on the virterror module please check the link https://libvirt.org.
Check if the virtMgr process is running. If not then check if the libvirt deamon is running on shell (Use command "ps | grep libvirtd"). If the libvirt deamon is running then start the virtMgr process using CLI command "start process virtMgr". Fetch the debug logs and the CLI command which failed to execute (if any) and contact technical support. If the virtMgr process is not running and if the libvirt deamon is not running too, then restart the switch. Fetch the core dump and the debug logs and contact technical support. - To fetch debug logs, configure the log filter as shown below before reproducing the issue. "configure log filter DefaultFilter add events VirtMgr severity debug-summary". - Reproduce the issue and fetch the logs using "show log" command. - To get the core dumps, restart the switch and fetch the latest core dump file (core.virtMgr.xxxx.s-1.gz) generated at "/usr/local/tmp" (internal memory) folder. - Use "tftp put <ip-address> core.virtMgr.xxxx.s-1.gz <remote-file>" to save the core dump to the desired location.
Warning
Handling a libvirt warning: %errorMessage% (virErrorNumber: %errorCode%, virErrorDomain: %errorDomain%)
| Name | Type |
|---|---|
| errorMessage | String |
| errorCode | uInt |
| errorDomain | uInt |